Skip to content

Fixing self imports for typeReference nodes#61107

Closed
navya9singh wants to merge 1 commit intomicrosoft:mainfrom
navya9singh:fix59827
Closed

Fixing self imports for typeReference nodes#61107
navya9singh wants to merge 1 commit intomicrosoft:mainfrom
navya9singh:fix59827

Conversation

@navya9singh
Copy link
Member

This pr fixes #58363 and #59827.

if (symbol.valueDeclaration && getSourceFileOfNode(symbol.valueDeclaration).path === sourceFile.path) {
existingLocals.add(symbol);
}
else if (!symbol.valueDeclaration && symbol.parent?.valueDeclaration && getSourceFileOfNode(symbol.parent.valueDeclaration).path === sourceFile.path) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think this is right. I'm not sure we ever should have been using valueDeclaration at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you think using valueDeclaration is wrong? Also, another way I had thought of was to do something like this
if (symbol.declarations && some(symbol.declarations, d => getSourceFileOfNode(d).path === sourceFile.path)) { existingLocals.add(symbol); }
but this again would go into another loop and check for each declaration which might probably end up taking even more time. Another way could be to do something like findAllReferences. I'm not exactly clear on what happens there but possible some way of comparing text to see which symbols already exist in a file. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

valueDeclaration only includes value-meaning declarations, and the failing test case here makes it clear why that’s not sufficient. I think looking at symbol.declarations is correct.

@typescript-bot
Copy link
Collaborator

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

  • For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
  • Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
  • Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate

@github-project-automation github-project-automation bot moved this from Waiting on author to Done in PR Backlog Mar 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Author: Team For Milestone Bug PRs that fix a bug with a specific milestone

Projects

Status: Done

4 participants